Semiconductor technology has advanced at a high rate over the past several decades, resulting in electronic devices with enormous complexity, such as very large scale integration (VLSI) processors. Each such electronic device typically consists of a large number of diverse subsystems; the interaction between these subsystems is also very complex. The likelihood of design errors within the electronic device increases with increased interaction between the subsystems. Accordingly, the cost of converting an electronic device design into a physical device still remains very high since a design error present in the physical device is very costly to correct.
Elimination of design errors as early as possible in a design cycle of the electronic device helps minimize the overall design period and also reduces associated development costs. Interaction between subsystems of the electronic device design is thus extensively tested prior to committing the electronic device design to physical form. In one example of this testing, subsystems of the electronic device design are repeatedly simulated to test the interaction between the subsystems, and between the subsystems and external devices, to identify design errors.
Though it is desirable to test as many of these interactions as possible, the amount of testing is limited by time and cost. Therefore, any increase in the efficiency of testing, and/or in the computer aided design (CAD) tools that facilitate this testing, results in improved device reliability and/or reduced development time and cost.
In addition, the latest generation of processors include a particularly diverse range of subsystems that require improved design and development techniques. For example, modern high performance multi-core processors (such as the Hewlett Packard/Intel “Montecito” processor) represent ultra-complex integrated circuit design and, as such, challenge CAD tools and development techniques. Extensive testing is thus required, particularly prior to reducing the multi-core processor design to physical form.
Within the multi-core processor, memory agents handle memory operations or transactions that access memory (e.g., shared memory and caches). For example, a processor core may read a line of memory stored in one or more locations within the multi-core processor, such as in the shared memory and caches. The memory agents cooperate to determine the source from which the line of memory should be read for the multi-core processor.
The memory agents, shared memory and caches may connect in a number of ways, such as by a bus or by a point to point link using a suitable protocol. A single memory transaction may therefore be quite complex, involving transmission of requests and data back and forth among the memory agents, shared memory and caches. The sequence of transmissions depends upon the locations and states of the line of memory and the bus protocol employed. Testing the operation of the memory agents is an extremely complex and data-intensive procedure.
A point to point link is a switch-based network that may have one or more crossbars that act as switches between the memory agents, shared memories, the processing cores, and other devices. Transactions on the point to point link are packet-based; each packet has a header with routing and other information. Information within the transactions is thus directed to specific locations within the multi-core processor and are routed appropriately by the crossbars.
FIG. 1 is a flowchart illustrating one prior art process 100 for testing, modifying and re-testing an electronic device design prior to committing the electronic device design to physical form. In step 102, process 100 creates one or more test cases for the electronic device design. Each test case typically employs one or more stimuli, used during simulation of the electronic device design, and one or more predicted outputs (‘expectations’). In one example, step 102 is performed by a design engineer who creates one or more tests for the electronic device design. In another example, step 102 is performed automatically by an Electronic Computer Aided Design (E-CAD) analysis tool that processes the electronic device design to produce the test cases.
In step 104, process 100 simulates the electronic device design and performs the tests of step 102. For example, in step 104, circuitry of all or part of the electronic device design is entered into an E-CAD simulation tool. The simulation uses the stimuli of each test case (from step 102) to produce simulation output.
In step 106, process 100 compares simulation output of step 104 to the predicted output of step 102, and logs results for each test case. Step 106 may, for example, send error messages to an engineering design terminal to indicate detected errors. In one example of step 106, process 100 compares, for each test case, simulation output of step 104 to predicted output of step 102, indicating that the test is successful if the simulation output matches the predicted output. If, in step 106, process 100 determines that an unexpected event occurred during simulation step 104, process 100 indicates that incorrect operation of one or more subsystems of the electronic device design has occurred. In another example of step 106, process 100 does not receive a predicted event of step 102, again indicating incorrect operation of one or more subsystems of the electronic device design. In another example of step 106, process 100 determines that the simulation output does not match the predicted output of step 102, again indicating incorrect operation of one or more subsystems of the electronic device design.
Step 108 is a decision. In step 108, if one or more errors are detected in step 106, process 100 continues with step 110; otherwise process 100 terminates, indicating that testing of the electronic device design is complete and that the electronic device design operates correctly. If no errors are detected in step 108, for example, process 100 terminates and indicates that the electronic device design is ready for manufacture. In step 110, process 100 modifies the electronic device design to correct errors detected in step 106, or, in certain cases, modifies the expected output, determined in step 102, to change error definitions.
Steps 104, 106, 108 and 110 are typically repeated many times, each iteration correcting problems identified in the electronic device design and/or test cases. When no errors are detected in step 106, the electronic device design is considered to operate correctly for all test cases created in step 102. If no further testing of the electronic device design is required, process 100 terminates and the electronic device design is committed to physical form.
Once the device is manufactured, it is again tested for correct operation and, if successful, the electronic device is often mass produced. If further errors are detected, the electronic device design may again be modified 110 in process 100 and then re-tested with additional test cases.
During operation of process 100, one design error typically causes many test errors, often resulting in duplicate and bogus error indications. Where the test case simulates interaction between one or more subsystems, a design error within one subsystem may therefore result in a plurality of cascaded error messages from process 100. These cascaded error messages (including repeated error messages) may obscure real errors in the system. A verification engineer is therefore required to carefully search through all reported errors to identify the real errors. This searching is difficult and time consuming, resulting in additional development time and cost.
Design modification step 110 of process 100 may thus require extensive analysis of transaction and error logs to identify real errors in the electronic device design. This transaction and error log analysis is often very labor intensive and can occur many times during the development of the electronic device design. The large number of transaction and error log messages created during simulation of the electronic device design makes it difficult for the verification engineer to identify fundamental causes of error, resulting in development delays and increased development costs. In one example, the verification engineer manually traces back through many hundreds of transaction and error log messages to determine fundamental causes of error in memory agent transactions. Further, the error messages and logging information typically produced by process 100 are both voluminous and cryptic, requiring skilled interpretation.